Claude Code borró 2,5 años de registros de una web de producción siguiendo instrucciones al pie de la letra

Los laboratorios de inteligencia artificial llevan meses argumentando que sus agentes autónomos están listos para encargarse de tareas complejas con mínima intervención humana. El caso de Alexey Grigorev, un desarrollador que usó Claude Code para migrar su infraestructura en AWS y acabó perdiendo 2,5 años de registros de su base de datos en cuestión de segundos, ilustra con precisión el lado menos publicitado de ese argumento.

Grigorev quería mover su web, AI Shipping Labs, a AWS y hacer que compartiera infraestructura con otro de sus proyectos, DataTalks.Club. Para gestionar toda esa infraestructura, usaba Terraform, una herramienta muy extendida en entornos profesionales que permite definir en código todos los recursos de un sistema en la nube: servidores, bases de datos, redes, sistemas de copias de seguridad. La gran ventaja de Terraform es precisamente esa capacidad de crear entornos completos a partir de un archivo de configuración. Su gran riesgo es el mismo: también puede destruirlos.

¿Qué es Terraform y por qué es especialmente peligroso en manos de un agente?

Terraform funciona comparando el estado actual de la infraestructura con el estado deseado descrito en sus archivos de configuración. Para hacer esa comparación, necesita un archivo de estado que registra exactamente qué recursos existen en cada momento. Si ese archivo falta o está desactualizado, Terraform puede llegar a conclusiones erróneas sobre qué hay que crear, modificar o eliminar.

Grigorev encargó a Claude Code que planificara la migración, pero olvidó subir el archivo de estado actualizado antes de empezar. El agente procedió, creó recursos duplicados y fue detenido a mitad del proceso. Hasta ahí, un error manejable. El problema llegó cuando Grigorev subió el archivo de estado y le pidió a Claude que identificara y limpiara los recursos duplicados, dando por hecho que el agente entendería el contexto completo de la situación.

Claude no lo entendió. O, más precisamente, lo entendió de la única manera que podía, a saber, de forma literal. Con el archivo de estado en su poder, el agente ejecutó un comando de destrucción de Terraform para eliminar lo que consideraba configuración incorrecta y preparar el entorno para rehacerlo bien. El problema es que ese archivo de estado incluía también toda la infraestructura de DataTalks.Club. En cuestión de segundos, ambas webs, sus bases de datos y las instantáneas que servían como copias de seguridad quedaron eliminadas.

El error humano y el error del sistema

En el análisis posterior, Grigorev fue honesto consigo mismo: había delegado demasiado en el agente. Le había dado permisos amplios sobre un entorno de producción real, había asumido que Claude comprendía el contexto de dos proyectos distintos que compartían infraestructura y no había revisado manualmente el plan de ejecución antes de que se llevara a cabo la operación destructiva.

Pero reducir esto a un error de usuario sería simplificar demasiado. La otra cara del problema es que los agentes de IA como Claude Code siguen instrucciones con una literalidad que no siempre encaja con la forma en que los humanos trabajan. Un administrador de sistemas junior, ante una situación ambigua, probablemente habría hecho una pausa y preguntado. Claude ejecutó.

Esto se confronta directamente con el discurso que los propios laboratorios de IA mantienen sobre la autonomía de sus agentes. OpenAI, Anthropic y otros llevan meses presentando los agentes autónomos como el siguiente paso natural en la evolución de estas herramientas, capaces de gestionar tareas complejas de principio a fin. Lo que el caso de Grigorev recuerda es que esa autonomía tiene un coste si no va acompañada de los controles adecuados. Un agente que no cuestiona, no avisa y no distingue entre limpiar duplicados y destruir producción no es un colaborador, es una herramienta de precisión quirúrgica que no sabe cuándo parar.

Amazon Business pudo restaurar los datos en aproximadamente un día, por lo que la historia tiene un final razonablemente feliz. Grigorev ha publicado las medidas que está aplicando desde entonces: protecciones de borrado en Terraform y AWS, pruebas periódicas de restauración de base de datos, almacenamiento del archivo de estado en S3 en lugar de en local, y una regla personal de revisar manualmente cualquier plan que implique operaciones destructivas antes de ejecutarlo. También ha quitado a Claude Code la capacidad de ejecutar comandos de Terraform directamente.

Fin del Artículo. ¡Cuéntanos algo en los Comentarios!